Thanks for the iterative fixes addressing the review checklist. The base_model inheritance is clean — both models correctly reference existing models/alibaba/ metadata, override only provider-specific fields (narrower context, text-only modalities, attachment = false), and let limit.output inherit from the base (65,536) rather than copying the context length. interleaved is correctly omitted since the reasoning field isn't one of the two schema-allowed names.

A few items to address before merge:

1. type = "toggle" is unverified (should fix)

Both models declare [[reasoning_options]] type = "toggle", but the PR body doesn't document the toggle mechanism. The audit-reasoning-options skill is explicit:

Only add toggle if all of these are true: The same provider model ID can run with reasoning enabled and disabled. The caller controls the state through a documented or reproduced request. The exact field and values are known.

If that sentence cannot be completed and cited or reproduced, do not claim toggle.

The PR confirms chat completions, streaming, and tool calls, and that reasoning arrives in a separate reasoning field — but never tests or cites the toggle control itself. Since BlueClaw runs vLLM (you mention reading the max_model_len error), the standard Qwen3 toggle would be chat_template_kwargs: {enable_thinking: false}. Two options:

• If you can verify it: send a request with chat_template_kwargs: {"enable_thinking": false} and confirm reasoning is suppressed, then add a comment per the AGENTS.md guidance:

  [[reasoning_options]]
  type = "toggle" # API: {"chat_template_kwargs": {"enable_thinking": false}}

• If you can't verify it: use reasoning_options = [] — the AGENTS.md says "Use reasoning_options = [] when the model reasons but exposes no verified control."

For comparison, orcarouter and deepinfra use reasoning_options = [] for this same model, while llmtr adds a top-of-file comment explicitly stating "this claim is unproven" before declaring toggle. Either approach is more transparent than an unqualified type = "toggle".

Consider also adding a brief reasoning-surface comment to provider.toml, following the pattern in providers/evroc/provider.toml or providers/llmtr/provider.toml — even a one-liner saying the toggle is vLLM-standard or undocumented helps future reviewers.

2. Logo fidelity (should confirm)

The final vector SVG (patch 3) meets the technical guidelines (square viewBox, currentColor, no fixed size). However, the path data appears to be a hand-crafted approximation rather than a faithful vectorization of BlueClaw's actual logo — the original patch 1 used the real favicon as a PNG-embedded SVG, and patch 3 replaces it with a single closed blob path that doesn't obviously correspond to the original. Can you confirm this path represents the actual BlueClaw brand mark? If no official vector asset exists and the PNG-embedded approach (as used by orcarouter/atomic-chat/hpc-ai) is more brand-accurate, that may be preferable even though it doesn't fully meet the currentColor guideline.

3. Minor: status = "beta"

The PR body describes the service as a "free fair-use beta." Consider setting status = "beta" on both models to reflect the lifecycle stage, matching how scaleway marks the same Qwen3.6-35B-A3B model.

4. Minor: doc URL

doc = "https://blueclaw.network" points to the main site. If there's a dedicated docs or models page, that would better satisfy the schema's intent ("a link to the provider documentation where models are listed").

Summary: Items 1 and 2 should be resolved before merge. The base_model structure, provider TOML, and model file layout are all correct.

Review: feat(blueclaw): add Blue Claw provider

Verdict: Request changes — one reasoning_options accuracy issue to resolve; the rest of the PR is solid.

What's correct

• Logo (providers/blueclaw/logo.svg): vector SVG, viewBox="0 0 24 24", fill="currentColor". Compliant with the logo guidelines; the favicon → hand-traced vector approach is reasonable given no published vector asset.
• base_model: both models correctly inherit from alibaba/qwen3.6-35b-a3b and alibaba/qwen3.6-27b (both exist). Overrides are limited to what the endpoint actually differs on (attachment = false, text-only modalities.input, narrower limit.context). limit.output correctly inherits the base 65_536 rather than being copied from the context length.
• interleaved omission: correct — BlueClaw returns reasoning in a reasoning field, which isn't one of the two field names (reasoning_content/reasoning_details) the schema allows.
• status = "beta": appropriate for a free fair-use beta; no [cost] block is acceptable for a free offering.
• provider.toml: @ai-sdk/openai-compatible + api + env + doc all satisfy the provider schema.
• No sync module: justified — the source endpoint can't populate context limits (context was read from a vLLM max_model_len error), so it isn't rich enough to be authoritative.

Blocking concern: reasoning_options toggle is unverified

Both models declare:

[[reasoning_options]]
type = "toggle"

The PR body justifies this as "matching how evroc/nearai declare the same FP8 model." Per the audit-reasoning-options skill, that is explicitly not valid evidence:

Do not add an option merely because a model reasons internally or another provider exposes that control.

The skill's toggle standard requires all three of:

1. The same model ID can run with reasoning enabled and disabled.
2. The caller controls the state through a documented or reproduced request.
3. The exact field and values are known.

And requires completing this sentence before accepting a toggle:

Qwen/Qwen3.6-35B-A3B-FP8 toggles reasoning with <request path> set to <enabled value> or <disabled value>.

The PR body confirms reasoning output exists (a separate reasoning field) and verifies chat/streaming/tool calls, but never verifies that reasoning can be turned off via a specific request field. As a side note, the cited evroc precedent is itself inconsistent — providers/evroc/provider.toml states "evroc documents OpenAI compatibility but no toggle, effort, or budget field; the raw reasoning-control surface is undocumented," yet its model file still claims toggle, so it isn't reliable precedent.

Since BlueClaw is vLLM-based, the toggle very likely works via chat_template_kwargs.enable_thinking: false — but that needs to be confirmed against the live endpoint, not assumed from a neighbor.

Requested change: either

• verify the toggle against the endpoint (send a request with chat_template_kwargs: {enable_thinking: false} and confirm the reasoning field disappears) and document the exact field in the PR body, or
• downgrade both models to reasoning_options = [] ("the model reasons, but no user-selectable control was verified through this provider").

Minor / non-blocking

• doc URL: https://blueclaw.network points to the marketing site rather than a model-listing docs page. The schema accepts it, but if there's a page listing the served models or an API reference, prefer linking that.
• Please confirm bun validate passes locally before merge (I couldn't run it with the tools available here).